Target-based smb and dce/rpc processing for an intrusion detection system or intrusion prevention system

ABSTRACT

A method performed in a processor of an intrusion detection/prevention system (IDS/IPS) checks for valid packets in an SMB named pipe in a communication network. In a processor configured as an IDS/IPS, a packet in a transmission is received and a kind of application of a target of the packet is determined. Also, the data in the packet is inspected by the IDS/IPS as part of the SMB named pipe on only one of a condition that: (a) the FID in an SMB command header of the packet is valid (i) for segments/fragments in the SMB named pipe and (ii) for the determined kind of application of the target of the packet, as indicated by a reassembly table, and (b) the determined kind of application of the target of the packet does not check the FID, as indicated by the reassembly table.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a divisional application of U.S. application Ser.No. 13/484,628, filed May 31, 2012, which is a continuation of U.S.application Ser. No. 12/575,612, now issued as U.S. Pat. No. 8,272,055,filed Oct. 8, 2009, which claims the benefit of the U.S. ProvisionalApplication No. 61/103,630 filed Oct. 8, 2008. The entirety of each ofthese applications is incorporated herein by reference.

TECHNICAL FIELD

The present invention relates in general to network traffic analysis,and more specifically to analyzing server message block (SMB) commandpackets in a SMB named pipe, and analyzing distributed computingenvironment/remote procedure call (DCE/RPC) request fragments in aDCE/RPC request, optionally in connection with intrusiondetection/prevention.

BACKGROUND

An SMB command, which is utilized in packet network communications, canbe separated into multiple packets that are sent to the targetdestination, as part of the same SMB named pipe. The multiple packetscan be reassembled by the destination to re-create the original SMBcommand.

Also, a DCE/RPC request utilized in packet network communications can beseparated into request fragments which are sent to the destination, aspart of the same DCE/RPC request. Each request fragment still belongs tothe original DCE/RPC, and can be reassembled by the destination tore-create the original DCE/RPC request.

The inventor has noted that different kinds of operating systems and/orapplications have unique methods of SMB packet reassembly and DCE/RPCfragment reassembly. For example, different WINDOWS™ and SAMBA™ versionshandle SMB and DCE/RPC processing differently. These methods ofreassembling DCE/RPC request fragments and/or SMB command packets can beexploited by attackers.

The conventional IDS/IPS is not sensitive to these differences, and mayreassemble the SMB packets, SMB transaction fragments/segments and/orDCE/RPC request fragments differently than the target destination host.The reassembled SMB command or DCE/RPC request analyzed by the IDS/IPSmay be different from the SMB command or DCE/RPC request reassembled bythe SMB or DCE/RPC processing at the target destination host.Consequently, an attack that successfully exploits these differences inreassembly can cause the IDS/IPS to miss the malicious traffic. Anattacker may use such an evasion to exploit a vulnerability and gounnoticed.

BRIEF SUMMARY

Accordingly, one or more embodiments of the present invention providemethods, systems, and computer readable memory mediums, in a processorof an intrusion detection/prevention system (IDS/IPS), for checking forvalid packets in an SMB named pipe in a communication network. Anembodiment includes receiving, in a processor configured as an IDS/IPS,a packet in a transmission and determining a kind of application of atarget of the packet in response to receiving the packet. Also providedis including, in the IDS/IPS, the data in the packet as part of the SMBnamed pipe data inspected by the IDS/IPS as part of the SMB named pipeon only one of a condition that: (a) the FID in an SMB command header ofthe packet is valid (i) for segments/fragments in the SMB named pipe and(ii) for the determined kind of application of the target of the packet,as indicated by a reassembly table, and (b) the determined kind ofapplication of the target of the packet does not check the FID, asindicated by the reassembly table.

Another embodiment provides methods, systems and computer readablememory mediums, in a processor of an intrusion detection/preventionsystem (IDS/IPS), for checking for valid packets in an SMB named pipe ina communication network. The embodiment can include receiving, in aprocessor configured as an IDS/IPS, a fragment/segment, and determininga kind of application of a target of the fragment/segment in response toreceiving the fragment/segment. The embodiment also can includeseparating, in the IDS/IPS, fragments/segments with a same multiplex ID(MID) as part of a same SMB transaction command from fragments/segmentswith a different MID, the MID being in the SMB frame header, all forfragments/segments in the same SMB named pipe, when a reassembly tableindicates that the kind of application of the target separates based onMID. Also, the embodiment can include processing, in the IDS/IPS, thesame SMB transaction command with the same MID as being in a separateSMB transaction command instead of with the fragments/segments with thedifferent MID when the kind of application of the target separates basedon MID.

Still another embodiment provides methods, systems and computer readablememory mediums, in a processor of an intrusion detection/preventionsystem (IDS/IPS), for reassembling distributed computingenvironment/remote procedure call (DCE/RPC) request fragments. Theembodiments can include receiving, in a processor configured as anIDS/IPS, plural request fragments belonging to a single DCE/RPC request.Also, the embodiment can include determining, in the IDS/IPS, the kindof application of a target of the DCE/RPC request. Furthermore, theembodiment can include selecting, in the IDS/IPS, one of the requestfragments as a source of a context ID depending on the target kind ofapplication as indicated in a reassembly table. Also, the embodiment caninclude reassembling, in the IDS/IPS, the plural request fragments intoa reassembled request. Further, the embodiment can include inserting, inthe IDS/IPS, the context ID from the selected request fragment into thecontext ID of a DCE/RPC header of the reassembled request.

Yet another embodiment provides methods, systems and computer readablememory mediums, in a processor of an intrusion detection/preventionsystem (IDS/IPS), for reassembling request fragments. The embodiment caninclude receiving, in a processor configured as an IDS/IPS, pluralrequest fragments belonging to a single request. Also included isdetermining, in the IDS/IPS, the kind of application of a target of therequest. Also included is selecting, in the IDS/IPS, one of the requestfragments as a source of an operation number as indicated in areassembly table depending on the target kind of application. Furtherincluded is reassembling, in the IDS/IPS, the plural request fragmentsinto a reassembled request. Also provided is inserting, in the IDS/IPS,the operation number from a DCE/RPC header of the selected requestfragment into the operation number of a DCE/RPC header of thereassembled request.

Further, the purpose of the foregoing abstract is to enable the U.S.Patent and Trademark Office and the public generally, and especially thescientists, engineers and practitioners in the art who are not familiarwith patent or legal terms or phraseology, to determine quickly from acursory inspection the nature and essence of the technical disclosure ofthe application. The abstract is neither intended to define theinvention of the application, which is measured by the claims, nor is itintended to be limiting as to the scope of the invention in any way.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying figures, where like reference numerals refer toidentical or functionally similar elements and which together with thedetailed description below are incorporated in and form part of thespecification, serve to further illustrate various exemplary embodimentsand to explain various principles and advantages in accordance with thepresent invention.

FIG. 1 is a diagram illustrating a simplified and representativeenvironment associated with segment analysis;

FIG. 2 is a diagram illustrating a prior art SMB named pipe processing;

FIG. 3 is a diagram illustrating target-based SMB processing accordingto a first embodiment;

FIG. 4 is a diagram illustrating another prior art SMB transactioncommand processing;

FIG. 5 is a diagram illustrating target-based SMB processing accordingto a second embodiment;

FIG. 6 is a diagram illustrating a prior art DCE/RPC processing;

FIG. 7 is a diagram illustrating target-based DCE/RPC processingaccording to a third and fourth embodiment;

FIG. 8 is a block diagram illustrating portions of an exemplary computersystem;

FIG. 9 is a block diagram illustrating portions of an SMB frame headerand an SMB command header;

FIG. 10 is a block diagram illustrating portions of a DCE/RPC requestheader;

FIG. 11 is a flow chart illustrating a process to check for validpackets in an SMB named pipe according to the first embodiment;

FIG. 12 is a flow chart illustrating a process to check for validpackets in an SMB named pipe according to the second embodiment; and

FIG. 13 is a flow chart illustrating a process to reassemble DCE/RPCrequest fragments according to the third and fourth embodiments.

DETAILED DESCRIPTION

In overview, the present disclosure concerns analysis of network trafficon communication networks, often referred to as packet switchingnetworks, which support communication from wireless and/or wire linedevices to a destination. Such communication networks may carry SMBcommands which have been split at the SMB level into plural packets,and/or DCE/RPC requests which have been split at the DCE/RPC level intovariable sized transmission control protocol (TCP) segments. Moreparticularly, various inventive concepts and principles are embodied insystems, devices, and methods therein for analyzing segments, optionallyin connection with intrusion detection/prevention systems.

The instant disclosure is provided to further explain in an enablingfashion the best modes of performing one or more embodiments of thepresent invention. The disclosure is further offered to enhance anunderstanding and appreciation for the inventive principles andadvantages thereof, rather than to limit in any manner the invention.The invention is defined solely by the appended claims including anyamendments made during the pendency of this application and allequivalents of those claims as issued.

Relational terms such as first and second, and the like, if any, areused herein solely to distinguish one from another entity, item, oraction without necessarily requiring or implying any actual suchrelationship or order between such entities, items or actions. Someembodiments may include a plurality of processes or steps, which can beperformed in any order, unless expressly and necessarily limited to aparticular order; i.e., processes or steps that are not so limited maybe performed in any order.

Much of the inventive functionality and many of the inventive principleswhen implemented, are best supported with or in software or integratedcircuits (ICs), such as a digital signal processor and softwaretherefore, and/or application specific ICs. It is expected that one ofordinary skill, notwithstanding possibly significant effort and manydesign choices motivated by, for example, available time, currenttechnology, and economic considerations, when guided by the concepts andprinciples disclosed herein will be readily capable of generating suchsoftware instructions or ICs with minimal experimentation. Therefore, inthe interest of brevity and minimization of any risk of obscuring theprinciples and concepts according to the present invention, furtherdiscussion of such software and ICs, if any, will be limited to theessentials with respect to the principles and concepts used by theexemplary embodiments.

Consider the series of steps in the following example in connection withnamed pipes:

Login/Authenticate returns UID.Connect to IPC$ share-returns TID-needs a valid UIDOpen named pipe-returns FID-needs a valid UID and TID that opened IPC$share

Login

Connect to IPC$ shareOpen named pipe-say lsrvsvc FID1Open named pipe-say\spoolss FID2

Write to FIDI Write to FID2 Write to FID 1 Write to FID2 Write to FID IWrite to FID2

Read from FID1-gets results of data/request sentRead from FID2-gets results of data/request sent

On a very basic level, the IDS/IPS needs to be aware of the differentnamed pipes being written to so that the IDS/IPS does not munge all ofthe data together. Say an attacker is using FID1 to send an exploit andsay the exploit spans two writes:

Write to FID 1

Write to FID2--->exploit

Write to FID1 Write to FID2 Write to FID1 Write to FID2

If the IDS does not separate the data going to each of the named pipesit will likely miss the exploit. It should be separating the data likeso:

Write to FID1 Write to FID2 Write to FID1 Write to FID2 Write to FID1Write to FID2

The UID/TID/FID relationship needs to be understood on a per targetbasis so an attacker can't slip in invalid data between writes toobscure an attack. Say for the Windows XP case:

Login-UID1 Login-UID2

Connect to IPC$ share using UID I-TID1Open named pipe using UID1/TID1 FID1Write to FID1 using UID1/TID1/FID1Write to FID1 using UID2/TID1/FID1--->exploitWrite to FID1 using UID1/TIDI/FID1 - - - 1

The server will not accept the second write, so the IDS should notinclude the data in the second write for desegmentation/defragmentationand evaluation.

Now, consider the series of steps in the following example in connectionwith an SMB transaction:

Login-UID1

Connect to IPC$ share using UID1 TID1Open named pipe using UID1/TID1 FID1

Transact-UID1/TID I/FID1 MID I/PID1 Transact-UID1/TID1/FID I MID2/PID2Transact Sec-MIDI/PID1

Transact Sec-MID2/PID2---->exploit

Transact Sec-MID1/PID1 Transact Sec-MID2/PID2 Transact Sec-MID1/PID1Transact Sec-MID2/PID2

The server will collect these segments until the total data for each SMBtransaction is sent and then send to the named pipe. The data should beseparated like this:

Transact-UID1/TID1/FID1 MID1/PID1 Transact Sec-MID1/PID1 TransactSec-MID1/PID1 Transact Sec-MIDI/PID1 Transact-UID1/TID1/FID1 MID2/PID2Transact Sec-MID2/PID2 Transact Sec-MID2/PID2 Transact Sec-MID2/PID2

These and other problems in SMB and DCE/RPC processing can be addressedby various embodiments.

Further in accordance with exemplary embodiments, target-based SMBand/or DCE/RPC processing can provide an IDS/IPS the ability to maintainthe same state and to reassemble both segmented SMB requests and/orfragmented DCE/RPC requests as does the target destination host. Thiscan preclude evasion attacks since both the IDS/IPS and the destinationhost are in the same state and reassemble SMB segments and/or DCE/RPCfragments identically.

Referring now to FIG. 1, a diagram illustrating a simplified andrepresentative environment associated with segment analysis will bediscussed and described. In the illustration, an intruder 101 (such as acomputer system) transmits a transmission to a destination 109. In thisexample, the transmission is transmitted via a network 103, a router105, and a firewall 107 to the destination 109. The communications tothe destination 109 can be monitored in accordance with well knowntechniques by an intrusion detection/prevention system 111, such as witha sensor. Although this illustration provides a sensor behind thefirewall 107, the sensor can be provided anywhere before the destination109. Alternatively, the intrusion detection/prevention system 111 can beprovided in-line with the destination 109, or can be incorporated intothe destination 109.

An SMB command in a transmission can be segmented at the SMB layer intopackets or segments (sometimes referred to herein as fragments orfragments/segments) in accordance with known techniques. Also, a DCE/RPCrequest can be fragment at the DCE/RPC layer into DCE/RPC requestfragments. The packets and segments are sent to the destination 109, andthe destination 109 reassembles the packets and fragments into the SMBcommand or DCE/RPC request, as appropriate. The order in which thedestination 109 reassembles packets and fragments is a by-product of theSMB layer processing or DCE/RPC layer processing, alone or incombination with the particular operating system on the destination 109.The method in which packets or fragments are reassembled by anapplication in combination with a particular operating system can beexploited by the intruder 101. Note that although this illustrationassumes an intruder 101 sending transmissions or fragments, transmissionor fragments that are analyzed can be sent from anywhere.

The illustrated IDS/IPS 111 includes portions for managing 113 packetreconstruction to handle SMB named pipe instance, managing 115 packetreconstruction to handle transaction tracking, reassembling 117 DCE/RPCfragments with context ID sensitivity, and reassembling 119 DCE/RPCfragments with operation number sensitivity (respectively, first,second, third and fourth embodiments). The IDS/IPS can include acombination of one, two, three, or four of the portions 113, 115, 117,119. Conveniently, the portions 113, 115, 117, 119 can be provided as apreprocessor to the IDS/1PS, that is, to process data before it isevaluated for intrusion.

A first embodiment for processing SMB commands is discussed inconnection with FIG. 2 (prior art), FIG. 3, and FIG. 11. A secondembodiment for processing SMB commands is discussed in connection withFIG. 4 (prior art), FIG. 5, and FIG. 12. A third embodiment and fourthembodiment for processing DCE/RPC requests are discussed in connectionwith FIG. 6 (prior art), FIG. 7, and FIG. 13. Each of these embodimentsis discussed in detail below.

First Embodiment

In accordance with known techniques for an SMB named pipe, a user logsin (is assigned a unique UID), opens a share (is assigned a tree id(TID)), and opens an SMB named pipe (is assigned a file id (FID)). Eachof the UID, TID, and FID is unique. The standard SMB header has fieldsfor UID and TID and FID.

Different operating systems and their SMB applications (hereafter, an“OS/application combination”) have different requirements for how toopen an SMB named pipe for each of these within an SMB session.

In some OS/application combinations, it does not matter what UID or TIDor FID is used—in other combinations, the FID matters, and perhaps theUID and/or TID matter. In some OS/application combinations, when a fileis opened, it matters whether particular UIDs and TIDs are used whenthat FID is opened—others, not. It is ultimately the SMB layer on thetarget of the SMB request that handles the SMB request. For Windows,because Windows is closed source it unknown whether it is the kernel ora separate application that handles the SMB layer, such as a servicehost. In LINUX or UNIX, Samba is in an application layer. The presentinventor noticed that different applications respond differently to thesame UID, TID and FID in an SMB request.

An IDS/IPS traditional includes a preprocessor which formats the databefore being evaluated for intrusions, among other things. One of themain purposes of the preprocessor is to do defragmentation, includingdeciding which named pipe instance a fragment belongs to.

With SAMBA 3.0.22 (as an example), the SMB request only needs the FID(without regard to UID and TID) to always get the same pipe instance.

So, as packets are coming in, one needs to know which named pipe thepacket is going to be handled as in the target system in order toproperly reassemble and evaluate fragments and packets for differentkinds of OS/application combinations. (Both fragments or segments aresplit into fragmented or segmented packets at the application layer(unlike handling of IP fragments and TCP segments).

The key: as a target system is connected up, some combination of theUID, TID and/or FID may have to be specified, or not, depending on theOS/application combination at the target. It can be important to be ableto identify whether or not a particular access is valid, as connectionsand transactions are tracked that go across that named pipe.

Referring now to FIG. 2, a diagram illustrating a prior art SMB namedpipe processing will be discussed and described. This illustrates anevasion example: someone sends a FRAG1 (valid packet 203, which containsfirst half of exploit), FRAG2 (invalid packet 205 due to incorrect FIDwhich will be ignored by the application on predetermined kinds ofOS/application combinations of the target 211), and FRAG3 (valid packet207, which contains second half of exploit). Each of these is on thesame named pipe 201. Without this invention, the IDS/IPS sees all threefragments/packets 219, 221, 223 on a named pipe 225, whereas the targetoperating system sees only FRAG1 and FRAG3, which have the first half ofexploit 213 and second half of exploit 215, together creating an exploit217. The IDS then misses the attack or falsely alerts since the exploitspans FRAGI and FRAG3, in this example with an intervening packet 205.

A first embodiment can improve the handling of SMB. A lookup table forSMB named pipe reassembly can be included in the IDS/IPS or itspreprocessor, for the combination of OS/application targeted by the SMBrequest. The OS/Application combination (e.g., Windows 2003) can belooked up and returned by known technology. The lookup table can containindications of how to process FID, and/or FID/UID/TID, and even whetheror not to check the FID/UID/TID for each of predetermined OS/applicationcombinations. The IDS/IPS or its preprocessor accordingly can flexiblyand accurately handle SMB commands targeted to different OS/applicationcombinations.

The SMB packet is received, and based on its IP address theOS/application (e.g., WINDOWS VISTA) is returned, and then the table isreferenced for checking the FID, and/or FID/UID/TID based on the IPaddress. The named-pipe processing makes sure that the FID (in theappropriate context of the UID and TID, i.e., if required by theOS/application that is processing the SMB request) is valid for thesegments/fragments. The lookup table can be set up which stores the UIDand TID used to open the FID. Thus, after the pipe is open, checking canbe done as to whether the FID is valid, given the UID and TID, furtherdepending on the application on the target that is processing the SMBrequest.

As a concrete example, for UID, the system can check whether there was avalid login. Also, the system can check whether UID and TID in therequest previously were used to open the named pipe, for example,Windows Vista. There are different requirements depending on theOS/application combination at the target as to whether or not therequest is valid.

Referring now to FIG. 3, a diagram illustrating target-based SMBprocessing according to a first embodiment will be discussed anddescribed. FIG. 3 can be compared to FIG. 2 (prior art) to appreciatethe more effective result. FIG. 3 illustrates a failed evasion example:a valid packet 303 contains first half of exploit, a packet 305 which isinvalid due to incorrect FID, and a valid packet 307 contains secondhalf of exploit. Each of these is on the same named pipe 301. TheIDS/IPS 309 determines the kind of application of the target of thepacket, and determines whether the application has special handling forpackets with FID, UID, and/or TID and what that handling is, for exampleby referring to the SMB named pipe reassembly table 310. In the presentexample, the named pipe reassembly table for the present target systemindicates that FID is checked, and a fragment with incorrect FID is notincluded as part of the data for the named pipe. (For other targetsystems, the named pipe reassembly table indicates that packets with aninvalid FID are not ignored, or that packets with an invalid UID and/orTID are not included as part of the data for the named pipe. Theinformation in the table is predetermined to match SMB handling ofdifferent kinds of applications.) The valid packets 303, 307 areincluded as data in the SMB named pipe 323. Since the invalid packet 305is not included as part of the data for the SMB named pipe, the IDS/IPSevaluates the two fragments 319, 321 as data in the SMB named pipe 323.In this example, both the IDS/IPS and the target see only the two validpackets 319, 321, 313, 315, which have the first half of exploit andsecond half of exploit, together creating an exploit. The IDS thenaccurately notes the exploit that spans the first and third packets 303,307.

Second Embodiment

The second embodiment further considers the effect of the PID (processID) and/or MID (multiplex ID) on the reassembly of SMBfragments/segments into SMB transaction commands by the IDS/IPS prior tothe evaluation of the transaction commands by the IDS/IPS.

The transaction command, such as an SMB command, writes data to thenamed pipe. The MID and PID fields are important if the transaction issegmented. The application at the target needs to keep track of thesecondary transaction commands' MID and PID to make sure the segment isbeing put into the right place.

A transaction SMB command causes the data to be written to the namedpipe only when all of the segments are received by the target. Anattacker can interleave an exploit with the secondary transactioncommands. Segments for different transaction commands can beinterleaved. The MID and PID fields indicate which transaction thesegments belong to. In a typical transaction, none of the data iswritten to the pipe until all of the segments are gotten by the server.If two transactions are going at the same time, the IDS/IPS can moreaccurately identify intrusion events if it knows which transaction thesegments belong to.

At the source end of the named pipe is the DCE/RPC processor.

Referring now to FIG. 4, a diagram illustrating another prior art SMBtransaction command processing will be discussed and described. Thisillustrates an evasion example: FRAGA 403 (main SMB transaction, withsame MID and PID, which contains first half of exploit), FRAGB 405(secondary SMB transaction, with an MID different from FRAGA 403 but thesame PID in the SMB frame header), FRAGC 407 (secondary SMB transaction,with the same MID as FRAGA 403 but a different PID in the SMB frameheader), and FRAGD 409 (secondary SMB transaction with the same MID andPID as FRAGA 403, which contains the second half of the exploit). Eachof these is on the same named pipe 411. The conventional IDS/IPS 413sees the data in all four fragments/packets 423, 425, 427, 429 as belongto one or more transaction commands 431, whereas the target operatingsystem sees only FRAGA and FRAGD, which contain the first half ofexploit 417 and second half of exploit 419, together creating an SMBtransaction command 421 with an exploit. The conventional IDS/IPS thenmisses the attack or falsely alerts since the exploit spans FRAGA andFRAGD in this example, with intervening packets 405, 407.

A second embodiment can improve the handling of SMB. A lookup table forSMB transaction reassembly can be included in the IDS/IPS or itspreprocessor, for the combination of OS/application targeted by the SMBrequest. The OS/Application combination (e.g., Windows 2003) which is onthe target can be looked up and returned by known technology. The lookuptable can contain predetermined indications of how to separatefragments/segments in the same SMB named pipe and collect them into SMBtransaction commands, based on the MID and/or PID, for each ofpredetermined OS/application combinations. The IDS/IPS or itspreprocessor accordingly can flexibly and accurately evaluate SMBtransactions which are targeted to different OS/applicationcombinations.

The SMB fragment/segment is received, and based on its IP address theOS/application (e.g., WINDOWS VISTA) is returned, and then the table isreferenced for checking the MID and/or PID based on the OS/applicationof the target. The table can indicate whether the kind of OS/applicationseparates fragments/segments with a different MID and/or PID intodifferent SMB transaction commands.

Referring now to FIG. 5, a diagram illustrating target-based SMBprocessing according to a second embodiment will be discussed anddescribed. In FIG. 5, the data in the SMB transaction command arereassembled for evaluation by the IDS/IPS just as it is assembled by thetarget. Furthermore, by referencing the SMB transaction reassembly table514 to determine whether to sort the fragments by MID, and whether tofurther sort the fragments by PID, the single IDS/IPS 513 can accuratelyevaluate SMB transactions transmitted to different kinds ofOS/application combinations which reassemble the data in the fragmentsdifferently from each other.

Compare FIG. 4 to FIG. 5, with the same evasion example: FRAGA 503 (mainSMB transaction, with same MID and PID, which contains first half ofexploit), FRAGB 505 (secondary SMB transaction, with an MID differentfrom FRAGA 503 but the same PID in the SMB frame header), FRAGC 507(secondary SMB transaction, with the same MID as FRAGA 503 but adifferent PID in the SMB frame header), and FRAGD 509 (secondary SMBtransaction with the same MID and PID as FRAGA 503, which contains thesecond half of the exploit). Each of these is on the same named pipe511. In FIG. 5, the IDS/IPS 513 determines the kind of application ofthe target of the packet, and determines whether the kind of applicationhas special handling for packets in the same SMB named pipe with MIDand/or PID and what that handling is, for example by referring to theSMB transaction reassembly table 514. In the present example, the SMBtransaction reassembly table 514 for the present target system indicatesthat fragments/segments are processed in the same SMB transactioncommand when they have the same MID and same PID. (For other targetsystems, the SMB transaction reassembly table can indicate that the MIDand PID are not used for grouping fragments/segments into a single SMBtransaction command, or that the MID (but not PID) is used forgrouping.) FRAGA 523 and FRAGD 525 have the same MID and PID, andtherefore the IDS/IPS 513 using the SMB transaction reassembly table 514considers them to belong to a single SMB transaction command 527. FRAGB529 and FRAGC 533 are included as data in the SMB transaction command527. Since the fragment/segments with either a different MID ordifferent PID are not included as part of the SMB transaction command527 analyzed by the IDS/IPS 513, both the IDS/IPS and the target see thesame SMB transaction command 527, 521, which has the first half ofexploit and second half of exploit, together creating an exploit. TheIPS/IDS 513 then accurately notes the exploit that spans FRAGA 503 andFRAGD 509.

Third Embodiment

The third embodiment further considers the effect of the context ID onthe reassembly of DCE/RPC request fragments into DCE/RPC requests by theIDS/IPS prior to the evaluation of the DCE/RPC requests by the IDS/IPS.

Every DCE/RPC request has a context ID in the DCE/RPC header which is ahandle that refers to the interface to which the request is made. If therequest is fragmented, each fragment has only a part of the request;each fragment also has a context ID. The fragments are put back togetherto reassemble the DCE/RPC request. Although the fragments each include acontext ID, only one of the fragments needs to have the context ID forthe target application to put the fragments back together into thereconstituted request. However, the fragment that the target applicationselects from which to obtain the context ID is dependent on the targetOS/application. For example, WINDOWS(SM) obtains the context ID from thefirst fragment, but SAMBA contrarily uses the last fragment. The presentinventor has performed tests and observed that the fragment to select asproviding the source of the context ID varies according to the recipientOS/application. Hence, it can be important to select the context ID froma correct one of the fragments so as to better emulate the target.

The context ID is a known field in the DCE/RPC request header. However,there is no standard which dictates the fragment to use for obtainingthe context ID for a reassembled DCE/RPC request.

The context ID identifies a collection of functions for remote procedurecalls. In comparison to embodiment 4 (discussed below), the operationnumber (sometimes referred to as an opnum) identifies a function withinthat collection of functions. Together, the context ID and operationnumber identify the service and the function within that service that isbeing called. By using a context ID and/or operation number as used bythe target, the IDS/IPS can determine whether that data in the remoteprocedure call will exploit a particular vulnerability within thatservice. If the IDS is not tracking the context ID that is used by theOS/application, then it will not put fragments together the same as thetarget OS/application (a so-called “DCE/RPC exploit”).

Consider a DCE/RPC exploit spanning a couple of fragments in a DCE/RPCrequest. The exploit is based on the function call within that service.If the IDS/IPS uses the wrong context ID, then the IDS/IPS is checking anon-existent service or wrong service to identify the exploit, whichthen could go unnoticed.

The IDS/IPS gathers together the request fragments. If the target isWindows, for example, then the first fragment is stored with its contextID as being the correct context ID. Later, when all of the fragments arereassembled and the request header is added (according to knowntechniques), the fragment which is the source of the context ID storedinto the request header of the reassembled packet, is predetermined andselected based on the recipient OS/application since the fragment thecontext ID comes from varies depending on the target OS/application.

The third and/or fourth embodiments can be implemented with SMBprocessing or even TCP connection/non-SMB.

Referring now to FIG. 6, a diagram illustrating a prior art DCE/RPCprocessing will be discussed and described. This also illustrates anevasion example: DCE/RPC Request FRAG A 603 (context ID A, and op numX), DCE/RPC Request FRAG B 605 (context ID B, op num Y), and DCE/RPCRequest FRAGC 607 (context ID B, op num Z, and an exploit for context IDB, op num Z). Each of these belongs to a single DCE/RPC request 601. Theconventional IDS/IPS 613 interprets the fragments as belonging to asingle DCE/RPC request 633 and hence does not evaluate the contents ofthe fragments the same as the target 615. The target OS/application inthis application interprets operating system sees FRAGA 619, FRAG B 621,and FRAG C 623, together in a DCE/RPC request 625 with a DCE/RPC requestheader using context ID B and op num Z (from last fragment). The serviceand function call for context ID B and op num Z are vulnerable to theexploit which was not noticed by the IDS/IPS because the conventionalIDS/IPS did not evaluate the context ID and op num from the samefragment as the target.

A third embodiment can improve the handling of DCE/RPC requestfragments. A lookup table for DCE/RPC context ID (and in someembodiments, a separate lookup table for DCE/RPC op num reassembly) andcan be included in the IDS/IPS or its preprocessor, for the combinationof OS/application targeted by the DCE/RPC request. The concept of thelook table is discussed above. The IDS/IPS or its preprocessoraccordingly can flexibly and accurately evaluate DCE/RPC requestsreconstructed from fragments.

Referring now to FIG. 7, a diagram illustrating target-based DCE/RPCprocessing according to a third and fourth embodiment will be discussedand described. In FIG. 7, the fragments FRAG A 703, FRAGB 705, FRAGC 707in a single DCE/RPC request 701 are reassembled into a DCE/RPC requestfor evaluation by the IDS/IPS 701 just as it they assembled by thetarget 715. Furthermore, by referencing the DCE/RPC context IDreassembly table 714 to select which fragment to use as the source ofthe context ID, the IDS/IPS 713 can prepare DCE/RPC request headers withaccurate context IDs, despite the DCE/RPC requests being transmitted todifferent kinds of OS/application combinations. Use of a DCE/RPCoperation num reassembly table 712 similarly results in preparing theDCE/RPC request headers with accurate operation numbers.

Compare FIG. 6 to FIG. 7, with the same evasion example: DCE/RPC RequestFRAG A 703 (context ID A, and op num X), DCE/RPC Request FRAG B 705(context ID B, op num Y), and DCE/RPC Request FRAGC 707 (context ID 13,op num Z, and an exploit for context ID B, op num Z). Each of thesebelongs to a single DCE/RPC request 701. The IDS/IPS 713 references theDCE/RPC context ID reassembly table to select which of the fragments isthe source of the context ID in the header for the reassembled DCE/RPCrequest. Because the header of the reassembled DCE/RPC request 735 whichis evaluated by the IDS/IPS has the same context ID as the header 717 ofthe DCE/RPC request 725 at the target 715, the IDS/IPS can notice aDCE/RPC exploit.

Fourth Embodiment

The fourth embodiment further considers the effect of the operationnumber on the reassembly of DCE/RPC request fragments into DCE/RPCrequests by the IDS/IPS prior to the evaluation of the DCE/RPC requestsby the IDS/IPS. The fourth embodiment is similar to the thirdembodiment, except that the operation number is referenced instead ofthe context ID. Hence, most of the discussion of the third embodiment isnot repeated here.

The context ID and operation number can be obtained from differentfragments, depending on the kind of target. For example, for the contextID, all Windows versions use the first fragment as the source of thecontext ID, but for the operation number, only Windows Vista uses thefirst fragment as the source of the context ID.

Referring now to FIG. 8, a block diagram illustrating portions of anexemplary computer system 801 will be discussed and described. Thecomputer system 801 may include one or more controllers 805, which canreceive signals from a sensor 803 which senses communications from anetwork 835 in accordance with known techniques, where thecommunications are being sent to a target (not illustrated). Thecontroller 805 can include a processor 807, a memory 813, an optionaldisplay 809, and/or an optional user input device such as a keyboard811.

The processor 807 may comprise one or more microprocessors and/or one ormore digital signal processors. The memory 813 may be coupled to theprocessor 807 and may comprise a read-only memory (ROM), a random-accessmemory (RAM), a programmable ROM (PROM), and/or an electrically erasableread-only memory (EEPROM). The memory 813 may include multiple memorylocations for storing, among other things, an operating system, data andvariables 815 for programs executed by the processor 807; computerprograms for causing the processor to operate in connection with variousfunctions such as receiving 817 a transmission, determining 819 a kindof application of the target of the transmission, determining 821 a kindof application of the target of the fragment/segment, determining 823 akind of application of the target of a DCE/RPC request, including 825data in the packet as named pipe data in certain predeterminedsituations, determining 827 whether the UID/TID is valid for the FID,and excluding the data from the named pipe data when the UID and/or TIDis invalid for the FID, determining 829 whether the data includes anattack spanning plural packets, separating 831 fragments/segments byMID/PID, processing 833 the same SMB transaction command apart fromfragments/segments with a different MID/PID, selecting 835 apredetermined one of the request fragments as the source of context IDand selecting a predetermined one of the request fragments as a sourceof the operating number, reassembling 837 the fragments in a reassembledrequest, and/or other processing; an SMB named pipe reassembly table839, an SMB transaction reassembly table 841, a DCE/RPC context IDreassembly table 843, a DCE/RPC operation number reassembly table 845; akind of application database 847; and a database 849 for otherinformation used by the processor 807. The computer programs may bestored, for example, in ROM or PROM and may direct the processor 807 incontrolling the operation of the computer system 801.

The processor 807 optionally may be programmed for receiving 817 atransmission. In the illustrated example, fragments or packets aredetected by the sensor 803 connected to the computer system 801 and aresupplied to the computer system 801 in accordance with known techniques.

The processor 807 may be programmed for determining 819 a kind ofapplication associated with the target of the packet, determining 821 akind of application of the target of the fragment/segment, and fordetermining 823 a kind of application associated with the target of theDCE/RPC request. In the typical situation, the packet or fragmentidentifies the target, for example as a destination IP address found inthe packet header. A kind of application database 847 or table can bemaintained for known destinations, which indicates the kind ofapplication associated with a particular target. The kind of hostdatabase or table is intended to distinguish between applications and/oroperating systems that reassemble segments differently for SMB namedpipe processing, for SMB commands, and/or for DCE/RPC requests.Advantageously, a reassembly table or database can indicate whether andhow fragments are assembled (such as the order of assembly and whetherdata in a packet with an invalid FID, TID and/or UID is included in theSMB named pipe data or not). In the illustrated example, the SMB namedpipe reassembly table 839 includes two or more fragment reassemblypatterns, which can be indexed, for example by the kind of application.

The data can be provided, for example, by parsing the received fragmentsor packets, by accumulating data from the fragments or packets instorage in the order, or by data from the fragments or packets beingprovided as input for another process (for example the intrusiondetection/prevention unit).

The processor 807 may be programmed for including 825 data in the packetas named pipe data for certain predetermined applications. The data canbe included, for example, by accumulating data from the fragments orpackets in storage if the reassembly table indicates that it is added,or by data from the fragments or packets being provided as input foranother process (for example the intrusion detection/prevention unit).

The processor 807 may be programmed for determining 827 whether theUID/TID is valid for the FID, and excluding the data from the named pipedata when the UID and/or TID is invalid for the FID. Examples arediscussed herein.

The processor 807 may be programmed for determining 829 whether the dataincludes an attack spanning plural packets. Examples are discussedherein.

The processor 807 may be programmed for separating 831fragments/segments by MID/PID. Examples are discussed herein

The processor 807 may be programmed for processing 833 the same SMBtransaction command apart from fragments/segments with a differentMID/PID. Examples are discussed herein.

The processor 807 may be programmed for selecting 835 a predeterminedone of the request fragments as the source of context ID and selecting apredetermined one of the request fragments as a source of the operationnumber. Examples are discussed herein.

The processor 807 may be programmed for specifically reassembling 837the fragments in a reassembled request, and inserting the context ID andoperation number into the DCE/RPC header which is added to thereassembled request before it is evaluated by the IDS/IPS for anintrusion. The reassembling can be done by, for example, storing thedata from the fragments, in the order, in a storage location, torecreate the transmission. The recreated transmission can be providedfor further processing, for example, to the intrusiondetection/prevention unit.

An optional intrusion detection/prevention unit (not illustrated) can beincluded in the processor 807 can be programmed in accordance with knowntechniques, to evaluate whether the packets or fragments (properlyassembled to match the behavior of the target) suggest an attemptedintrusion.

The processor 807 may be programmed for various reassembly tables 839,841, 843, 845. The reassembly tables 839, 841, 843 can be provided forimplementing the different reassembly patterns. One or more of thereassembly tables 839, 841, 843, 845 alternatively can be stored in aremote database and accessed as needed.

The processor 807 may be programmed for a kind of application database847. The kind of application database 847 can be maintained for knowndestinations, to indicate the kind of application associated with aparticular destination. Optionally, the kind of application database 847can be maintained remotely, and relevant kind of application informationcan be downloaded as needed. Optionally, the kind of application can beindicated in a table rather than a database.

It should be understood that various logical groupings of functions aredescribed herein. Different realizations may omit one or more of theselogical groupings. Likewise, in various realizations, functions may begrouped differently, combined, or augmented. Furthermore, functionsincluding those identified as optional can be omitted from variousrealizations. Similarly, the present description may describe or suggesta database or collection of data and information. One or moreembodiments can provide that the database or collection of data andinformation can be distributed, combined, or augmented, or providedlocally (as illustrated) and/or remotely (not illustrated).

FIG. 9 and FIG. 10 are included to summarize SMB fields (FIG. 9) andDEC/RPC fields (FIG. 10) that are referenced by one or more embodiments.The format of SMB commands and DCE/RPC requests are well understood inthe art.

Referring now to FIG. 9, a block diagram illustrating portions of an SMBframe header 923 and an SMB command header 925 will be discussed anddescribed. The SMB frame header 923 includes standard fields for a treeID (TID) 907, a process ID (PID) 909, a user ID (UID) 911, and amultiplex ID (MID) 913. The SMB command header 925 follows the SMB frameheader 923. If a command field 903 in the SMB frame header requires aFID, the FID 919 is included as a field in the SMB command header 925.The FID 919 is in the SMB command header 925 (for an SMB command, suchas write next, or transact, and other types of SMB write command). Otherfields 903, 915, 919, 921 typically are included in the SMB frame header923 and SMB command header 925.

Referring now to FIG. 10, a block diagram illustrating portions of aDCE/RPC request header 1009 will be discussed and described. The DCE/RPCrequest header 1009 includes standard fields for context ID 1003 andoperation number 1005. Other fields 1001, 1007 are typically included inthe DCE/RPC request header 1009.

FIG. 11, FIG. 12 and FIG. 13 are flow charts of procedures for analyzingSMB transmissions or DCE/RPC requests. FIG. 11 illustrates a procedurefor checking for valid packets in an SMB named pipe using FID/UID/TID,FIG. 12 illustrates a process for checking for valid packets in an SMBnamed pipe using MID/PID, and FIG. 13 is an illustration of reassemblingDCE/RPC request fragments while sensitive to a context ID and/oroperation number. These procedures can advantageously be implemented on,for example, a processor of a controller, described in connection withFIG. 8 or other apparatus appropriately arranged. Although these areillustrated as separate procedures, it will be appreciated that theprocedures of FIG. 11, FIG. 12 and FIG. 13 can be combined. FIG. 11,FIG. 12 and FIG. 13 are discussed in more detail below.

Referring now to FIG. 11, a flow chart illustrating a process 1101 tocheck for valid packets in an SMB named pipe according to the firstembodiment will be discussed and described. In overview, the process1101 includes receiving 1103 a packet in a transmission, determining1105 a kind of application of the target of the packet, judging 1107whether the FID is valid for the segments/fragments in the SMB namedpipe, judging 1109 whether the FID is valid for the kind of applicationof the target of the packet, judging 1111 whether the kind ofapplication of the target checks the FID, judging 1113 whether theUID/TID is valid for the FID, excluding 1115 data within the packet fromthe SMB named pipe data in the SMB named pipe, and including 1117 datafrom the packet as part of the SMB named pipe data in the SMB namedpipe. These are described below, however, details that have previouslybeen described are omitted.

The process 1101 can receive 1103 a packet in a transmission. The packetis received at the IDS/IPS. Because the packet is being evaluated by theIDS/IPS, the IDS/IPS will attempt to evaluate the packet as it will beinterpreted by the target. Therefore, the process 1101 can determine1105 a kind of application of the target of the packet. For example, theIP address of the target can be used to determine the kind ofapplication/OS combination which is used on the target using knowntechniques.

So that the IDS/IPS will accurately simulate how the application/OSinterprets data in the packets, data in the packets is included as partof the SMB named pipe data which the IDS/IPS inspects only if (A) theFID in the SMB command header of the packet is valid for both thesegments/fragments in the SMB named pipe and for the determined kind ofapplication of the target of the packet; or if (B) the kind ofapplication of the target of the packet does not check the FID. Thus,the process 1101 can judge 1107 whether the FID is valid for thesegments/fragments in the SMB named pipe, and can judge 1109 whether theFID is valid for the kind of application of the target of the packet.Also, the process 1101 can judge 1111 whether the kind of application ofthe target checks the FID. Because the data is included in the SMB namedpipe data only when the FID is valid for the particular kind ofapplication of the target, or when the target is of the kind that doesnot check the FID, the SMB named pipe data inspected by the IDS/IPS moreaccurately simulates the SMB named pipe data at the target. Effectively,the process can exclude 1115 data from the packet as part of the SMBnamed pipe data and can include 1117 data from the packet as part of theSMB named pipe data which is inspected by the IDS/IPS.

Optionally, the process 1101 can judge 1113 whether the UID and/or TIDis valid for the FID. In the event that the UID and/or the TID is notvalid for the FID, the data from the packet can be excluded from the SMBnamed pipe date which is inspected by the IDS/IPS.

Referring now to FIG. 12, a flow chart illustrating a process 1201 tocheck for valid packets in an SMB named pipe according to the secondembodiment will be discussed and described. In overview, the processincludes receiving 1203 a fragment/segment in a transmission in one SMBnamed pipe, determining 1205 a kind of the application of the target ofthe fragment/segment, judging 1207 whether the kind of application ofthe target separates fragments/segments based on the MID, separating1209 fragments/segments with the same MID as part of the same SMBtransaction command from fragments/segments with a different MID all inthe same SMB named pipe, judging 1211 whether the kind of application ofthe target separates based on PID, further separating 1213fragments/segments with the same MID and same PID as part of the sameSMB transaction command from fragments/segments with a different MID ordifferent PID all in the same SMB named pipe, processing 1215 the sameSMB transaction command as being a SMB transaction command separate fromthose with a different MID or PID, and processing 1217 thefragments/segments as part of the SMB transaction. Each of these isdescribed below, however, details that have previously been describedare omitted.

The process 1201 can receive 1203 a fragment/segment in a transmissionin one SMB named pipe. This has been described previously in sufficientdetail.

The process 1201 can determine 1205 a kind of the application of thetarget of the fragment/segment using any known process, as previouslydescribed.

The process 1201 can judge 1207 whether the kind of application of thetarget separates fragments/segments based on the MID, such as byreferring to a reassembly table. For example, the reassembly table canbe indexed by the kind of application and can indicate whether toseparate fragments based on MID. Equivalents can also be provided. Theprocess 1201 can separate 1209 fragments/segments with the same MID aspart of the same SMB transaction command from fragments/segments with adifferent MID all in the same SMB named pipe. In this case, thefragments/segments which are in the same SMB transaction have the sameMID.

The process 1201 can judge 1211 whether the kind of application of thetarget separates based on PID, for example by referring to a reassemblytable which indicates whether to separate fragments based on PID. Theprocess 1201 further can separate 1213 fragments/segments with the sameMID and same PID as part of the same SMB transaction command fromfragments/segments with a different MID or different PID all in the sameSMB named pipe. In this case, the fragments/segments which are in thesame SMB transaction have the same MID and PID.

The process 1201 then can process 1215 the same SMB transaction commandwith the same MID (and perhaps same PID as discussed above) as being aseparate SMB transaction, instead of with the different MID or PID,where the fragments/segments are all in the same SMB named pipe.

If the kind of application of the target does not separate based on MID,the process 1201 instead can process 1217 the fragments/segments as partof the SMB transaction.

Referring now to FIG. 13, a flow chart illustrating a process 1301 toreassemble DCE/RPC request fragments according to the third and fourthembodiments will be discussed and described. In overview, the processincludes receiving 1303 fragments belonging to a single DCE/RPC request,determining 1305 a kind of application of the target of the DCE/RPCrequest, selecting 1307 a predetermined request fragment as a source ofthe context ID, selecting 1309 a predetermined request fragment as asource of the operation num, reassembling 1311 the DCE/RPC request,inserting 1313 the context ID and the operation number from the selectedrequest fragment(s) into the DCE/RPC header of the reassembled requests,and evaluating 1315 the reassembled SMB request for intrusion. These aredescribed below, however, details that have previously been describedare omitted.

The process 1301 can receive 1303 fragments belonging to a singleDCE/RPC request. Also, the process 1301 can determine 1305 a kind ofapplication of the target of the DCE/RPC request. These have beenpreviously described in detail.

The process 1301 can select 1307 a predetermined request fragment as asource of the context ID. The predetermined request fragment isassociated with the kind of the application of the target. Thereby,different kinds of applications can indicate different requestfragments. The request fragment could be, e.g., the first (or last)request fragment in order in the DCE/RPC request, the first (or last)request fragment in a DCE/RPC request to be received, or someintermediate request fragment.

The process 1301 can select 1309 a predetermined request fragment as asource of the operation number. The request fragment which is the sourceof the operation number may be different from the request fragment whichis the source of the context ID.

The process 1301 can reassemble 1311 the DCE/RPC request, in accordancewith known techniques, and can prepare a DCE/RPC header for thereassembled request. However, in comparison to conventional techniques,the process 1301 can insert 1313 the context ID and the operation numberfrom the selected request fragment(s) into the DCE/RPC header of thereassembled requests.

Then, the process 1301 can evaluate 1315 the reassembled SMB request forintrusion in accordance with available IDS/IPS techniques.

Moreover, embodiments include a computer system configured with theforegoing computer-readable medium and/or method(s); and/or acommunication network comprising at least one computer system configuredwith the foregoing computer-readable medium and/or method(s).

It should be noted that the communication networks of interest includethose that transmit information in packets in accordance with SMB orDCE/RPC protocols, where the packets optionally can be formed into SMBsegments/fragments or DCE/RPC request fragments, for example, thoseknown as packet switching networks that transmit data, where data can bedivided into packets before transmission, the packets are transmitted,and the packets are routed over network infrastructure devices, whichare sent to a destination where the segments/fragments or packets can bereassembled into the packets. Such networks include, by way of example,the Internet, intranets, local area networks (LAN), wireless LANs(WLAN), wide area networks (WAN), and others. Protocols supportingcommunication networks that utilize packets include one or more ofvarious networking protocols having any link layers that support the TCPtransport layer, or any application that rides over the transport layer,and other wireless application protocols or wireline applicationprotocols and/or other protocol structures, and variants and evolutionsthereof. Such networks can provide wireless communications capabilityand/or utilize wireline connections such as cable and/or a connector, orsimilar.

SMB protocols include those known as SMB, SMB1, SMB2, Samba, Samba TNG,Linux SMB, CIFS, CIFS Client for Solaris, FreeBSD SMB, smbfs, Vision FS,JLAN, RTSMB, and variations and evolutions thereof Typically, SMBprotocol is operated between an SMB client and SMB server as source anddestination, with the IDS/IPS being neither. SMB mainly provides accessto file, printers, ports, and miscellaneous communications between theSMB client and SMB server.

DCE/RPC refers to a remote procedure call that supports access acrossmultiple computers, as if it were all accessing on the same computer, asspecified by the Open Group as DCE RPC 1.1, DCE RPC 1.2.2, DCE/RPC fromSamba TNG, FreeDCE, PC/DCE, MSRPC, and variations and evolutionsthereof.

Furthermore, the designation “intrusion detection/prevention system”(and IDS/IPS) is used herein to denote a device or software thatpassively or actively analyzes network traffic for intrusion. Examplesof such devices or software are sometimes referred to as “intrusiondetection system” (IDS), “intrusion prevention system” (IPS), “networkintrusion detection system” (NIDS), “network intrusion protectionsystem” (NIPS″), and the like, and variants or evolutions thereof. Anintrusion detection/prevention system may be host-based, or may monitortraffic to a target system using, for example, sensors, anywhere betweenthe target system and the intruder, typically after a final router orfirewall. The designation “intrusion detection/prevention” is usedherein to indicate the analysis of network traffic with respect tointrusion, whether the analysis is used passively (commonly referred toas “intrusion detection”) or actively (commonly referred to as“intrusion prevention”). Likewise, the designation “detect/prevent” isutilized to indicate either passive or active handling of intrusion,which may occur for example in an IDS, an IPS, or other software ordevice which incorporates an IDS or IPS function.

This disclosure is intended to explain how to fashion and use variousembodiments in accordance with the invention rather than to limit thetrue, intended, and fair scope and spirit thereof. The invention isdefined solely by the appended claims, as they may be amended during thependency of this application for patent, and all equivalents thereof.The foregoing description is not intended to be exhaustive or to limitthe invention to the precise form disclosed. Modifications or variationsare possible in light of the above teachings. The embodiment(s) waschosen and described to provide the best illustration of the principlesof the invention and its practical application, and to enable one ofordinary skill in the art to utilize the invention in variousembodiments and with various modifications as are suited to theparticular use contemplated. All such modifications and variations arewithin the scope of the invention as determined by the appended claims,as may be amended during the pendency of this application for patent,and all equivalents thereof, when interpreted in accordance with thebreadth to which they are fairly, legally, and equitably entitled.

What is claimed is:
 1. A method comprising: receiving, in a processorconfigured as an intrusion detection/prevention system, a packet in atransmission and determining a kind of application of a target of thepacket in response to receiving the packet; including, in the intrusiondetection/prevention system, data in the packet as part of a servermessage block inspected by the intrusion detection/prevention system aspart of the server message block named pipe on only one of a conditionthat: (a) a file identifier in a server message block command header ofthe packet is valid (i) for segments/fragments in the server messageblock and (ii) for the determined kind of application of the target ofthe packet, as indicated by a reassembly table, and (b) the determinedkind of application of the target of the packet does not check the fileidentifier, as indicated by the reassembly table.
 2. The method of claim1, wherein the reassembly table indicates whether and how differentkinds of applications check the file identifier in the server messageblock command header of the packet.
 3. The method of claim 1, furthercomprising determining, in the intrusion detection/prevention system,whether a user identifier in an server message block frame header of thepacket is valid for the file identifier in the segments/fragments in theserver message block, for the determined kind of application of thetarget, and including the data in the packet as part of the servermessage block data only if the user identifier is valid for the fileidentifier.
 4. The method of claim 1, further comprising determining, inthe intrusion detection/prevention system, whether a tree identifier inan server message block frame header of the packet is valid for the fileidentifier in the segments/fragments in the server message block, forthe determined kind of application of the target, and including the datain the packet as part of the server message block data only if the treeidentifier is valid for the file identifier.
 5. The method of claim 1,further comprising determining, in the intrusion detection/preventionsystem, whether a tree identifier and a user identifier in an servermessage block frame header of the packet are both valid for the fileidentifier in the segments/fragments in the server message block, forthe determined kind of application of the target, and including the datain the packet as part of the server message block data only if both thetree identifier and the user identifier are valid for the fileidentifier.
 6. The method of claim 1, further comprising inspecting inthe intrusion detection/prevention system, the data included as part ofthe server message block data, to determine whether the data includes anattack spanning plural packets.
 7. The method of claim 6, furthercomprising notifying the target of the packet that the data included aspart of the server message block data includes the attack spanningplural packets.
 8. An apparatus comprising: a network sensor configuredto sense packets in a server message block in a communication network;and a processor configured to: receive via the network sensor, a packetin a transmission and determine a kind of application of a target of thepacket in response to receiving the packet; include data in the packetas part of server message block on only one of a condition that: (a) afile identifier in a server message block command header of the packetis valid (i) for segments/fragments in the server message block and (ii)for the determined kind of application of the target of the packet, asindicated by a reassembly table, and (b) the determined kind ofapplication of the target of the packet does not check the fileidentifier, as indicated by the reassembly table.
 9. The apparatus ofclaim 8, wherein the reassembly table indicates whether and howdifferent kinds of applications check the file identifier in the servermessage block command header of the packet.
 10. The apparatus of claim8, wherein the processor is further configured to determine whether auser identifier in an server message block frame header of the packet isvalid for the file identifier in the segments/fragments in the servermessage block, for the determined kind of application of the target, andinclude the data in the packet as part of the server message block dataonly if the user identifier is valid for the file identifier.
 11. Theapparatus of claim 8, wherein the processor is further configured todetermine whether a tree identifier in an server message block frameheader of the packet is valid for the file identifier in thesegments/fragments in the server message block, for the determined kindof application of the target, and include the data in the packet as partof the server message block data only if the tree identifier is validfor the file identifier.
 12. The apparatus of claim 8, wherein theprocessor is further configured to determine whether a tree identifierand a user identifier in an server message block frame header of thepacket are both valid for the file identifier in the segments/fragmentsin the server message block, for the determined kind of application ofthe target, and include the data in the packet as part of the servermessage block data only if both the tree identifier and the useridentifier are valid for the file identifier.
 13. The apparatus of claim8, wherein the processor is further configured to inspect the dataincluded as part of the server message block data, to determine whetherthe data includes an attack spanning plural packets.
 14. The apparatusof claim 13, wherein the processor is further configured to notify thetarget of the packet that the data included as part of the servermessage block data includes the attack spanning plural packets.
 15. Amethod comprising: receiving, in a processor configured as an intrusiondetection/prevention system, plural request fragments belonging to asingle distributed computing environment/remote procedure call request;determining, in the intrusion detection/prevention system, a kind ofapplication of a target of the distributed computing environment/remoteprocedure call request; selecting, in the intrusion detection/preventionsystem, one of the request fragments as a source of a context identifierdepending on the target kind of application as indicated in a reassemblytable; reassembling, in the intrusion detection/prevention system, theplural request fragments into a reassembled request; and inserting, inthe intrusion detection/prevention system, the context identifier fromthe selected request fragment into context identifier of a distributedcomputing environment/remote procedure call header of the reassembledrequest.
 16. The method of claim 15, wherein the reassembly tableindicates which of the request fragments is selected as the source ofthe context identifier for each of different kinds of applications. 17.The method of claim 15, further comprising: selecting, in the intrusiondetection/prevention system, a different one of the request fragments asa source of an operation number depending on the target kind ofapplication; and inserting, in the intrusion detection/preventionsystem, the operation number from a distributed computingenvironment/remote procedure call header of the selected different oneof the request fragments in to the operation number of the distributedcomputing environment/remote procedure call header of the reassembledrequest.
 18. The method of claim 17, wherein the reassembly tableindicates which of the request fragments is selected as the source ofthe context identifier, and which different one of the request fragmentsis selected as the source of the operation number, for each of thedifferent kinds of applications.
 19. The method of claim 15, furthercomprising: selecting, in the intrusion detection/prevention system, theone of the request fragments as a source of an operation number; andinserting, in the intrusion detection/prevention system, the operationnumber from the distributed computing environment/remote procedure callheader of the selected request fragment into an operation number of adistributed computing environment/remote procedure call header of thereassembled request.
 20. The method of claim 19, wherein the reassemblytable indicates which of the request fragments is selected as the sourceof both the operation number and the context identifier for each of thedifferent kinds of applications.